The present disclosure generally relates to computer system applications, and more particularly, to discovering possible program variable values by connecting program value extraction with external data sources.
There are reasons why one may want to know what values a variable in a program can possibly take, either generally or at a specific point of program execution. One example is that one wants to ensure that the variable will always remain in a certain numeric range. Another example is that the variable is a string variable used to construct an SQL database query, and one wants to ensure that the result is always a valid SQL string. Yet another example is that the variable is the name of an external resource, such as a database, file, or message queue used, and one wants to find out what actual resources the variable might refer to.
While static analysis may be used to analyze static programs, as long as only the program code is considered, the value of many variables may not be known, or only partially known. Besides static analysis with automated tools, manual code inspection may be considered an option. However, modern programs are often large and complex. Typically, programs are obtained by assembling various components at runtime. As a result, it is very difficult to perform a manual analysis, and it is likely to be imprecise.
Run-time program monitoring can reveal typical values of program variables, but one is never sure that one has seen all possible values. For instance, it may not detect values that only occur under certain special conditions, such as partial failures, or after certain special inputs, if these special conditions do not occur during the monitoring time or those special inputs are not passed during the monitoring phase. Furthermore, run-time program monitoring is not always possible or ideal, for instance, because of security concerns or performance impact, or because one cannot introduce a monitor into an existing runtime environment.